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PROVIDING INTERNET PROTOCOL (IP) SECURITY 

TECHNICAL FIELD 

This invention relates to Internet Protocol Security. 

5 BACKGROUND 

Communication over the Internet requires a sender to send information over a 
network and a receiver to receive the information. Often senders desire confidentiality 
so that only certain receivers who have the senders' permission may receive the 
information. Senders encrypt their messages so only a select group of receivers who 
10 have a key to decrypt the message may receive the information. Malicious attacks 
occur when individuals try to gain access to the information without permission from 
the sender. 

SUMMARY 

The invention relates to providing Internet Protocol (IP) security. 

15 In general, in one aspect, the invention is a method of providing IP security 

(IPSec) at a network layer, that includes using two or more independent databases to 
process secure information, with a first database specifying a set of rules for the IP 
security and a level of security, and with a second database maintaining security 
information for at least two systems. 

20 This aspect may include one or more of the following features. The first 

database is cached and includes a plurality of security policy entries having at least a 
source IP address, a destination IP address, an IP protocol, a source port and/or a 
destination port. The first database uses a Practical Algorithm to Retrieve Information 
coded in Alphanumeric (PATRICIA) tree to look-up entries. 

1 
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The second database includes a pluraUty of security association end^^ 
define an IP destination, an IP security protocol, and a security parameter index. The 
second database uses a hash table to look-up entries. 

In general, in another aspect, the invention is directed to ah apparatus for 
is transmitting data packets. The apparatus includes a processor that executes 

instructions, and a memory that stores executable instructions for causing the processor 
to use two or more independent databases to process secure information. A first 
database specifies a set of rules for the IP security and a level of security, and a second 
database maintains security information for at least two systems. 
10 The embodiments may have one or more of the following advantages. For 

example/the security arrangements can provide strong, i.e., difficult to hack access 
control, connectionless integrity, data origin authentication, replay protection and 
confidentiality at the network layer. 

DESCRIPtlON OFTHE DRAWINGS 
is FIG^ 1 is a high-level block diagram representation of a network system. 

HG. 2 is a block diagram of an Internet Protocol Security (DPSec) software 
architecture. 

HG. 3 is a diagram that depicts Internet packet formats for encapsulation 
security payload (ESP). 
20 FIG* 4 is a diagram that depicts Internet packet formats for authentication 

header(AH).. 

FIG. 5 is a flowchart of IPSec outbound processing. 

HGv6 is a flowchart of n^Sec inbound pixx:essing: 
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FIG. 7 is a block diagram that depicts a Practical Algorithm To Retrieve 
Information Coded In Alphanumeric (PATRICIA) Tree for Security Policy Database 
(SPDP)and a hash tree for Security Association Database (SADB) for manual and 
automatic operation. 

5 

DETAILED DESCRIPTION 
Referring to FIG. 1, a typical network arrangement 10 is shown. The network 
arrangement 10 includes four different private networks 12a- 12d interconnected via a 
network 15 which can be the Internet, a Frame Relay (FR) network, Asynchronous 

10 Transfer Mode (ATM), etc. Each domain includes an IPSec Virtual Private Network 
(VPN) gateway (e.g., VPN gateway 14a- 14d), which provides a firewall, a server 
computer (e.g., server computer 16a-16b) and one or more clients (e.g., clients 19a- 
19c). A remote access server (RAS) 18 handles secure conununications between 
private networks, e.g., private networks 12a and 12b. The connection between the 

15 domains may be made using BPSec tunnel mode through IPSec tunnels 21a-21b. 

Access to RAS 18 may also be made by a dial-in modem 23. Network arrangement 10 
has two levels of security: (1) management and control message traffic from clients, 
19a-19c and (2) dial-in access from a dial in modem. Therefore, security is required 
from domain or dial-in locations. Thus, for instance, a user at a client 19b at private 

20 network 12b requires confidential communication with RAS 18 over the network 15. 

Referring to HG. 2, RAS 18 with Internet Protocol Security (IPSec) safeguards 
against malicious attacks at an application layer 40 by having the security processing 
performed at the network layer 60. The level of security afforded by use of the IPSec 
protocol depends on the type of IPSec software security architecture implemented. The 

3 
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IPSec software security architecture? 30 uses two ind^ a security 

policy Database (SPDB) 32 and a security association database (SADB) 34. The use of 
two separate independent databases offers strong access control, connectionless 
integrity, data origin authentication, replay protection and confidentiality at the netv/ork 
• ■ 5 layer. 

SADB 34 is a part of an ff Sec protocol engine 38. The ff Sec protocol 38 is 
connected to an automatic Internet Key Exchange (IKE) 42 through an IPSec SADB 
Interface 36. EKE 42 is a special application that establishes, in conjunction with ff Sec 
SADB interface 36, ffSec tunnels 21a-21b. IKE 42 ffSec also provides input to the 

10 Internet Secure Key Exchange Managenjent Protocol Security Asscknation (ISKMPSA) 
database 52 which functions as a link list to store keys. IPSec SADB interface 36 can 
also receive inputs manually through a manual SADB interface 48 using a command 
line interface (CLI). These inputs like all manual inputs in this description can be made 
from clients, 19a-19c (referring to FIG. 1). As explained below IPSec input messages 

15 54 and IPSec output 56 connect to ffSec SADB 36 interface to access SADB 34. An 
IPSec transform engine 58 provides the IPSec packet header and footer information. 

An IPSec SPDB interface 62 receives manual input from the manual SPDB 
interface 46 and from the IKE security policy configuration 44 and acts as an interface 
for SPi)B 32. IPSec iSPDB interface may be implemented using an Application 

20 Pro-am Ljterface (API) configuration. 

iBy placing SADB 34 and SPDB 32 at a network layer 60, net^^^ 
upper transport layer protocols 50 are both protected from malicious attacks. Inputs 
from application layer 40 through transport iayeir 50 of from network layer 60 are 
processed at the network layer 60 through a security policy check 64. As will be 

25 e?iplained below, SPDB 32 and SADB 34 are both used to process inbound and 

4 ;. • . 
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outbound messages. Each database is independent of the other database. In order for 
SPDB 32 and SADB 34 to function efficiently, the implementation of each database 
uses fast and flexible algorithms. SPDB 32 uses a modified Practical Algorithm to 
Retrieve information Coded in Alphanumeric (PATRICIA) trees for selector look-up 
5 while SADB 34 uses a hash table. 

SPDB 32 specifies rules for the type of packet traffic that is subject to IPSec 
processing and the level of IPSec protection. The level of protection includes whether 
to apply IPSec, bypass IPSec, or discard the packet. In other words, when a packet is 
received, the system will either apply IPSec to the packet, bypass IPSec and send the 

10 packet on to be processed, or discard the packet from the system. SPDP 32 contains an 
ordered list of policy entries keyed by one or more selectors. These selectors include 
source/destination BP address with or without subnet, IP protocol and source/destination 
port. SPDB 32 is typically cached in the system for performance benefit. 

SADB 34 is responsible for the security information for two systems, e.g., RAS 

15 18 and client 19b. Each IPSec security association is uniquely identified by an IP 
destination, an IPSec protocol, and a security policy index (SPI). The IPSec protocol 
specifies the IPSec protocol to be applied on the packet traffic for each security 
association. The protocol could be either in authentication header (AH) or 
encapsulation security payload (ESP) form. The SPI is a 32-bit identifier value used to 

20 distinguish among different security associations terminating at the same destination 
and using the same IPSec protocol. The SPI value is normally negotiated through an 
Internet Key Exchange (IKE). 

Each SADB entry defines the parameters for IP security processing. Typical 
parameters include sequence number counter, anti-replay window, data authentication 

25 algorithm and key (AH and ESP), data encryption algorithm and key, lifetime of the 

5 
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security association, md IPSec protocol mode (transpoit/tunnel). A sequence number 
counter is a 32-bit value used to generate a sequence nunaber for seiquence number 
fields in AH and ESP headers. The sequence number is generally used for outbound 
traffic. A sequence number counter is initialized b> zero and incremented 
5 monotonically. ITie anti-replay window is a 32-bit counter a^^ 

determine whether an inbound packet (authentication header (AH) or encapsulation 
security payload (JES?) protocol) is a replay event. A replay event is a malicious attack 
where a captured copy of legitimately communicated data (IP packet) is retransmitted 
for illegitimate purposes. The lifetinie of the security association is a time interval after 

10 which a security association is replaced with a new security association and new SPI or 
the security association is terminated. The lifetime also determines which of these 
actions should occur. It can be expressed as a time or a byte count, or both. If both are 
given one can be designated to take precedence such as the first to occur. 

Referring to HGS. 3 and 4, formats for the transport and tunnel modes are 

15 shown. TTie IPSec transport mode is used when the P security protocol header appears 
iimnediately after the original header. The IPSec tunnel mode has an "outer^* IP header 
specified for the IP processing destination and the 'inner" header specific the ultimate : 
destination for the IP packet The IP security protocol header appears after the "outef 
P header^ and before the ""inner^^IP header. 

20 Refening to HG. 5, during outbound IPSec pr^^ 

subject to a look-up 72 in the SPDB 34 based on pre-defined sel^ If a SPDB entfy 
is not found for a given selector, the IP packet 71 is forwarded for IP processing 76. If 
an SPDB entry 73 is found, the IPSec security poiicy is c^^ 
policy is Discard/the IP packet is dropped 77. If the security policy is Bypass, the P 

25 packet is forwarded to IP processing 76; ff the security policy is Appl^ 

■ 6 
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index (destination IP address, SPI and IPSec protocol) is retrieved 74 from the SPDB 
entry. The SADB index is used for SADB lookup 75. If the SADB entry is not found, 
the IP packet is dropped 77. If the SADB entry is found, the IP packet is forwarded for 
IPSec encapsulation 78. 

5 Referring to Figure 6, during inbound processing, if the IP packet is identified 

81 to be an IPSec packet by the IP protocol field. An SADB index is assembled 83 
using the parameters in IPSec header for a lookup in the SADB 84. If a SADB entry is 
not found, the IPSec packet is dropped 89. If a SADB entry is found, it is forwarded for 
IPSec decapsulation 85. The IP packet is tagged to be Apply IPSec and it is forwarded 

10 for a SPDB lookup 86. An unprotected IP packet 82 is also forwarded for a SPDB 
lookup 86. If a SPDB entry is not found, the IP packet is forwarded to IP processing 
90. 

If a SPDB entry is found, the IPSec security policy is checked 87. If the 
security policy is Discard, the IP packet is dropped 69. If the security policy is Bypass, 

15 the IP packet is forwarded to IP processing 90. If the security policy is Apply IPSec, 
the tag in the IP packet is retrieved 88. If the tag is Apply IPSec, the IP packet is 
passed to IP processing 90 because the packet has been successfully de-capsulated by 
the IPSec protocol engine. If the IP packet is not tagged, the IP packet is dropped 89. 
This process is used to safeguard attacks since the IP packet after de-capsulation 

20 cannot be distinguished from a spoofed IP packet. In summary, referring to FIGS. 2 
and 7, each IP packet or IPSec packet for both inbound and outbound IPSec processing 
uses one lookup in the SPDB 32 and one lookup in the SADB 36. Inputs into SPDB 32 
can be made through a Manual SPDB 92 via Manual SPDB interface 46 and inputs into 
SADB 34 can be made through a Manual SADB 93 via Manual SADB interface 48. 
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The SPDP look-up requires a fast and efficient algorithm because the software 
security architecture for ihe Internet Protocol has diverse selector keys based on 
destination address with ranges and wildcarding, source address with ranges and 
wildcarding, data sensitivity labeling (Internet Protocol Security Option/Commercisil 
5 Internet Security Option (ffSO /CIPSO) labels), transport layer protocols. User 
Datagram Protocol/Transmission Control Protocol (UDP/TCP) ports, and the 
possibility of future fields. Therefore, it is desirable to use variable length keys with 
combinations of masking and ranges. A hash table implementation is less preferred. A 
Practical Algorithm to Retrieve Informatiori Coded in Alphanumeric or PATOICIA tree 
10 implementation of the SPDB has the needed flexibility. 

By ad^ting the PATRICIA tree, SPDB Lookup can be done by modifying the 
software code. The following is an adaption of the PATRICIA Tree: 



typedef struct spd_key_data_s 

unsigned long dstjp_address; 
unsigned short dst_port; 
unsigned short protocol; 
unsigned long srcjp_address; 
unsigned short src^port; 
} spd_key jataj; 

#define SPD.DATA.SIZE sizeof(spd.key.data^t) 
typedef union spd data u 

spd_key^data_t spd^key; 

unsigned char spd_opaque_data[SPD_DATA„SIZE]; 
)spd_data_u; 

typedef struct spd data.s 

{ .• 

unsigned char spd Jen; 

unsigned char family; /* not used novv but could be */ 
unsigned short filler; /* keep everything aligned */ 
spd_data_u spd.data; 



15 



20 



25 



30 



35 



8 



wo 03/026196 



PCT/US02/29403 



} spd_data_t; 

#define CURRENT_SPD_DATA.LENGTH sizeof(spd.dataJ) 

5 /* adapted from the BSD route.h rtentry declaration */ 

struct spd.entry 

{ 

struct radix_node spd_nodes[2]; /* tree stuff -see Stevens page 569 */ 
unsigned long int gateway; 
10 K^SADB sa^key; 

unsigned char policy; 
unsigned short key; 



15 typedef struct spd_entry spd_entry; 

The following functions are used for insert, search and delete SPDB entry in the 
PATRICIA tree: 

20 spd_entry * spd_insert( spd_data_t * the_entry, 

spd_data_t *mask, 

unsigned long gateway, 

unsigned long spi, 

unsigned char policy, 
25 unsigned char protocol, 

unsigned short key; 

struct radix_node_head *spd„tree); 

spd_entry * spd_delete( spd_data_t * deletee, 
30 struct radix_node_head * spd_tree, 

spd_data_t *mask); 

spd_entry * spd_search(spd„data_t * spd_stuff, 

struct radix_node_head * spd_tree). 

35 

The keys for the PATRICIA tree include a source/destination IP Address, IP protocol 
and source and destination ports. In Internet Protocol Version 4 (IPv4), there is a 112 
bits in a key: 32 bits source IP address, 32 bits destination address, 16 bits source port, 
16 bits destination port and 16 bits IP protocol. Instead of using an 8-bit BP protocol, a 
40 16-bit IP protocol is used for alignment in PATRICIA tree. Masks are used to support 



9 
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both source IP address wildcard and destination IP address wildcard. Masks are also 
used if a match against IP protocol, source poit, and destinatidn port is required. 

Each node in a PATRICIA tree contains the PSec security policy and the index 
to SADB 36. The IPSec seciuity policy, which includes Apply IPSec, Bypass PSec 
5 and Discard, are defined and configured for outbound and inbound traffic on a per 
selector basis. 

Since each IPSec SADB entry is uniquely identified by a destination DP address, 
SPI, and iPiSec protocol (AH or ESP), a hash table is a suitable algorithni for SADB 
lookup 36. The hash table is a fast and efficient algorithni for table looku 

10 performance does hot degrade with large tablei entry. The divide by a prime is chosen 
over a multiplication method because the hash bucket is evenly distributed while the 
multiplication method tends to aggregate the hash bucket. Several modifications and 
parameters are applied to the basic divide by a prime hashing hash table to work in the 
ff Sec environment. These changes include hashing function modification and prime 

15 number^electidn. 

First, in hashing function modification, since the destination IP address, SPI, 
and ff Sec protocol uniquely identify the security association, the combination of these 
parameters can be used as a hash key in a hash table lookup for security association. 
The concatenation of IPy4 Destination IP address (32 bits), SPI (32 bits) and IPSec 

20 protocol (8 bits) is 72 bits. 72 bits is more than the 32-bit division that can be 
supported by a 32-bit central prociKsing unit (CPU). Thus, it is ineffid^ 
implement large number division using the basic 32-bit arithmetic operators. 
Therefore, a nrtixing function is used to mix and scramble these 72 bits into a 32-bit 
value prior to division by a prime number such as the following pseudo code: 



10 
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unsigned long result, hash; 

char *str; 

inti; 



5 hash = spi; 

result = hash » 24; 

hash = ((hash « 8) | result) ^ ip_protocol; 
str = (char *)&ip_address; 
for (i=0; i< 4; { 
10 result = hash » 24; 

hash = ((hash « 8) | result) ^ *str++; 



Second, a prime number is also selected to improve the efficiency. Since 
IS hundreds of SADB entries can reside in an IPSec enabled system, a suitable prime 

number is selected to meet both the performance requirement and memory requirement. 
From a list of prime numbers 53, 97, 193, 389. 769, 1543, 3079, 6151. 12289, 24593, 
389 is chosen to give the best solution between performance requirement and memory 
requirement. 

20 Other embodiments not described here are also within the scope of the 

following claims. 
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What is claimed is: 

1. A method of providing Internet Protocol 0P) security at a network layer, the 
method comprising: 

using two or more independent databases to process secure information, with a first 
5 database specifying a set of rules for the ff security and a level of security, and with a 
second database maintaining security information for at least two systems! 

2. The method of claim 1, wherein the first database includes a plurality of security 
policy entries. 

3. The method of claim 2, wherein the security policy entries include a source IP 
10 address, a destination IP address, an IP protocol, a source port, and/or a destination 

■- po^^- 

4. The method of claim 3, wherein the first database uses a Practical Algorithm to 
Retrieve Information coded in Alphanumeric (PATRICIA) tree to look-up entries. 

5. Hie method of claim 2, wherein the first database is cached. 

15 6. The method of claim 2, wherein the second database includes a plurality of security 
asfsodation entries. 

7. The method of claim 6, wherein each security association defines one or more 
paranieters required for the IP security. 

8. The method of claim 7, wherein a hash table is used to look-up entries. 
20 ?• The method of claim 7v wherein the one or more p^ 

destination, an IP security protocbl, and a security parameter index. 

10. The method of claim 8, wherein the IP security protocol is in an authentication 
header format. 

1 1. An apparatus for transmitting data packets, comprising: 
25 a processor that executes the instructions; and 

12 
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a memory that stores executable instructions for causing the processor to: 
use two or more independent databases to process secure information; 
a first database specifying a set of rules for the IP security and a level of security; and 
a second database maintaining security information for at least two systems. 
5 12. The apparatus of claim 1 1, wherein the first database includes a plurality of security 
policy entries. 

13. The apparatus of claim 12, wherein the security policy entries include a source IP 
address, a destination IP address, an IP protocol, a source port, and/or a destination 
port. 

10 14. The apparatus of claim 12, wherein the first database uses a Practical Algorithm to 
Retrieve Information coded in Alphanumeric (PATRICIA) tree to look-up entries. 

15. The method of claim 2, wherein the first database is cached. 

16. The apparatus of claim 11, wherein the second database includes a plurality of 
security association entries. 

15 17. The apparatus of claim 16, wherein security association defines one or more 
parameters required for the DP security. 

18. The apparatus of claim 17, wherein the one or more parameters include an IP 
destination, an IP security protocol, and a security parameter index. 

19. The apparatus of claim 16, wherein a hash table is used to look-up entries. 

20 20. The apparatus of claim 18, wherein the IP security protocol is in an authentication 
header format. 
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